iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 6
0

1. 一個好的軟體架構,可以將修改的程式碼量,降到最低程度,理想狀況為0

  1. 目標-使系統易於擴展,而不會因修改而產生較大的影響
  2. 透過將系統劃分為元件,並將元件安排到依賴階層中而實現的,這類階層結構可以保護較高層級的元件,免受到低層級元件的變更所影響

2. 越上層的元件,擁有越核心的商業邏輯

  1. 離I/O越遠的元件層級越高,離I/O越近的層級越
  2. 越上層的元件,擁有越核心的商業邏輯
  3. 用櫃檯小姐的故事來說明(參考連結1)
    想像一下你(user)今天走進一間公司(I/O),負責接待你的,請你填寫資料的是櫃檯小姐(低層級-處理實作),如果你是來談一筆大生意的,你會經過櫃檯,走到最裡面的落地窗辦公室,老闆正在那準備跟你討論(高層級-核心商業邏輯),我覺得這個說法滿容易想像和理解的,完整內容,請參考下方連結

3. 什麼是元件?

  1. 大 [系統層級← 元件層級←模組層級←類別層級←程式碼層級 ] 小
  2. 可單獨部署的單位,是系統在部屬的最小部分實體
  3. 讀這篇的時候,我一直把元件和模組搞混,後續Ch12有針對元件做一個好像有說,又沒什麼用的定義,一切都是需要感覺,總之我自己認定的是,兩者差異在是否可以被獨立部署,或是說獨立啟動而不需要依賴其他模組,舉例來說像是微服務,我接受是元件,可獨立部署,且包含一個以上的模組

4. 如果元件A應該被保護免於受到“元件B的改變”影響,那麼元件B應該依賴元件A,A←依賴←B,B中會 import A ,B知道A,但A不知道B

  1. (B)低層級實作細節,應該依賴於(A)高層級商業邏輯
  2. 前台客服,替顧客服務的內容(實作細節),應該遵守老闆的的規定(商業邏輯)
  3. 在這個部分,看懂書中p61頁的圖會滿有幫助的,其中有兩個重點,大板塊的是元件,箭頭的指向則是依賴關係,觀察依賴關係的時候,可以特別著重誰依賴誰,因此如果有變動,受影像的是哪一方,我認為本篇對我的學習重點是
    1. 學習使用 import 和看箭頭方向區分依賴關係,謹慎規劃不同模組或是類別間的依賴關係
    2. 理解 為何依賴方向,可以保護被依賴者,不受影響,資訊隱藏的好處

參考

  1. 搞笑談軟工-Clean Architecture(4):架構三原則首部曲—分層原則

上一篇
D05 CH7 | SRP 單一職責原則
下一篇
D07 CH9 | LSP 替換原則
系列文
30天|入門NestJs連載學習筆記26
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言